home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group95b.txt / 000038_icon-group-sender _Wed Jun 7 04:46:24 1995.msg < prev    next >
Internet Message Format  |  1995-09-18  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 7 Jun 1995 08:20:57 MST
  2. From: Nevin Liber <nevin@lectura>
  3. Message-Id: <199506071147.EAA10758@lectura.CS.Arizona.EDU>
  4. Subject: Re: Garbage collection vs files
  5. To: davidf@deci.mks.com (David J. Fiander)
  6. Date: Wed, 7 Jun 1995 04:46:24 -0700 (MST)
  7. Cc: icon-group-l@cs.arizona.edu
  8. In-Reply-To: <3qr2a1$afq@deci.mks.com> from "David J. Fiander" at Jun 3, 95 09:29:37 pm
  9. X-Mailer: ELM [version 2.4 PL23]
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=US-ASCII
  12. Content-Transfer-Encoding: 7bit
  13. Content-Length: 2227      
  14. Sender: nevin@lectura
  15. Errors-To: icon-group-errors@cs.arizona.edu
  16.  
  17. davidf@deci.mks.com (David J. Fiander) writes:
  18.  
  19. > Most lisps will properly close files during garbage collection.
  20. > Does iconx, or the code generated by iconc?
  21.  
  22. No.  I'm not sure why you would want to.  I can see doing it under
  23. LISP, since there is usually an interactive programming environment
  24. associated with it.  There is no such environment associated with
  25. Icon.
  26.  
  27. Also, closing open files at garbage collection time is not correct
  28. semantically speaking, since the program itself might be dependent on
  29. the underlying file system semantics.  For instance, on a local Unix
  30. disk (this is also hacked into NFS, but I digress), one is allowed to
  31. open a file and then remove it (technically, remove its directory
  32. entry), and still access the file until it is closed or the program
  33. terminates.  This is guaranteed for a Unix filesystem, and closing an
  34. open file descriptor at garbage collection time would break these semantics.
  35. (One could argue that one should not be dependent on tricks like this, but
  36. that is beyond the scope of this discussion.)
  37.  
  38. On a related note:  whenever I write a tool that takes a bunch of file
  39. names from the command line, or reads from &input if none are
  40. specified, I use a variation of the following routine:
  41.  
  42. procedure InputFiles(LInputFilenames[])
  43.  
  44.     local   sFilename
  45.     local   fInput
  46.  
  47.     if 0 = *LInputFilenames then {
  48.         return &input
  49.     }
  50.  
  51.     while sFilename := get(LInputFilenames) do {
  52.         if not (fInput := open(string(sFilename))) then {
  53.             write(&errout, &progname, ": cannot open ", image(sFilename),
  54.                 " for reading.")
  55.             next
  56.         }
  57.  
  58.         suspend fInput
  59.  
  60.         close(fInput)
  61.     }
  62.  
  63. end
  64.  
  65. And the caller looks something like:
  66.  
  67.     procedure main(LArguments)
  68.  
  69.     local    fFile
  70.  
  71.     ...
  72.  
  73.     every fFile := InputFiles ! LArguments do {
  74.         ProcessFile(fFile)
  75.     }
  76.  
  77. This way, I am sure to close all the files that I open, I don't close
  78. &input (I don't like to close files that I didn't open), and all the
  79. code to handle the case where there are no files specified on the
  80. command line is isolated to InputFiles().
  81. -- 
  82.     Nevin ":-)" Liber    nevin@cs.arizona.edu    (520) 293-2799
  83.                                       office:    (520) 621-1815
  84.  
  85.